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PROCEDE ET D1SPOSIT1F D'ANALYSE DE LA SECUR1TE D'UN SYSTEME 



D'INFORMATION 



La presente invention se rapporte au domaine des outils d'analyse et 
de rnaitrise de la securite des systemes d'information (SSI). 

Les outils de conception structuree d f un systeme d'information (teis 
que SADT ou SART) ne prennent pas en compte la securite du systertie. Les 

5 methodes gen6ralistes d'analyse du risque (telles que Marion, Meiisa, ou 
CRAMM) sont peu precises, et incapabies de mettre en evidence les failles 
techniques d'un systeme. Les outils de surete de fonctionnement (SDF) sont 
limites aux problemes de fiabilite et de disponibilite, mais ne prennent pas en 
compte la malveillance. Les systemes de detection d'intrusion (IDS pour 

10 "Intrusion Detection Systems") et les analyseurs de vulnerability ne 
fonctionnent que sur des systemes reels, sont specifiques d'un domaine 
restraint, et n'ont qu'une vision partielle de la securite. Les editeurs de strategie 
de securite fonctionnent selon le point de vue du defenseur seulement, et ne 
comportent pas de fonction d'analyse de la coherence de la securite, nfe ( de 

1 5 recherche des failles et des attaques possibles. p ... 

L'invention a pour objet un procede et un dispositif d'analyse d| la 
securite des systemes d'information qui repose sur la modelisation ei la 
simulation du systeme et des attaques possibles, pour analyser et mattriser la 
securite du systeme. 

20 Plus particulierement, un premier aspect de ('invention concerne un 

procede d'analyse de la securite d'un systeme d'information comprenant : 

-une phase de modelisation comprenant la modelisation du systeme 
d'information ; et, 

- une phase de simulation, comprenant la specification et la simulation 
25 d'attaques potentielles contre le systeme d'information. 

La phase de modelisation comprend la specification de Tarchitecture 
du systeme avec un ensemble de composants du systeme et des relations 
entre lesdits composants, c'est-a-dire suivant un modele 
composants / relations. 

30 De preference, des etats determines sont associes a chaque 

composant du systeme d'information, chaque £tat pouvant prendre une valeur 
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saine et une ou plusieurs valeurs non saines. Certains au moins desdits etats 

se rapportent respectivement a I'activite, a la confidentialite, a 1'integrite et/ou a 

la disponibiiite du composant auquel lis sont associes. 

De preference, la phase de modelisation comprend en outre la 
5 specification d'un ensemble de regies de comportement, notamment au plan 

du fonctionnement du systeme et au plan de la securite (regies de protection), 

associees aux composants du systeme. 

Selon un avantage de Invention, I'utilisateur peut adopter le point de 

vue du defenseur pendant la phase de modelisation, et le point de vue de 
10 I'attaquant pendant la phase de simulation. En iterant des phases de 

modelisation et des phases de simulation alternees, il parvient a maftriser la 

securite du systeme d'information. 

Selon un autre avantage, I'invention permet d'analyser la securite d'un 

systeme d'information sans intervention directe sur ceiui-ci. En effet, le 
15 lancement des attaques se fait sur un systeme virtuel, correspondant au 

systeme reel modelise. 

Avantageusement, I'analyse de la securite peut avoir lieu tres tot dans 
le processus de conception du systeme d'information, et notamment avant son 
deploiement physique. 
20 Le procede permet de modeliser un systeme d'information, en se 

limitant a ses aspects securite, et done en restant maitrisable par une personne 
humaine, grace a des concepts et principes simplificateurs. L'invention permet 
de traiter d'une facon gen6rique les aspects notamment techniques (e'est-a- 
dire lies aux caracteristiques techniques du systeme d'information), humains, 
25 proceduraux et physiques (par exemple geographiques). Un bon compromis 
entre realisme et simplicite de la modelisation permet a un utilisateur 
(typiquement le concepteur ou I'administrateur du systeme d'information, ou un 
a uditor techruque H<=» la R 6nurit6^ de modeliser le systeme d'information sans 
avoir a le reproduire completement. 
30 Le proc6d6 permet aussi de simuler avec realisme toutes les attaques 

connues dans le monde des systemes d'information. Ces attaques s'averent 
generiques, et peuvent s'appliquer aux domaines connexes des systemes 
d'information (securite physique par exemple). 
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II permet enfin de simuler avec realisms toutes les parades connues 
dans le monde des systemes d'information, qu'elles solent de prevention ou de 
detection. La modelisation des parades de prevention est realisee par des 
regies de s6curit6. La modelisation des parades de detection est realisee au 
5 moyen de metriques. 

En resume, le precede permet d'anaiyser en peu de temps la faisabilite 
d'un tres grand nombre d'attaques sur un systeme donne. Avec un peu 
d'experience, Putilisateur peut simuler environ 100 a 200 attaques elementaires 
par jour, ce qui est considerablement plus que ce qu'on pourrait faire sur un 
10 systeme reel 

Un second aspect de ('invention concerne un dispositif pour la mise en 
oeuvre d'un procede selon le premier aspect. A cet effet, le dispositif comprend 
avantageusement une interface Homme / machine pour la mise en ceuvre de la 
phase de modelisation et/ou un moteur attaques / parades pour la mise en 
1 5 oeuvre de la phase de simulation 

Avantageusement, Pinterface Homme / machine presente une v 
fonctionnalite d'affichage en multi vues du systeme modelise. 

De preference, interface Homme / machine permet d'afficher le. 
systeme modelise selon un modele composants / relations. 
20 Le dispositif est destine a etre utilise en tant qu'outil d'audit technique 

de la securite des systemes d'information existants (e'est-a-dire deja deployes), 
pour lesquels il presente I'avantage de ne pas les perturber pendant leur 
exploitation. II peut notammeht analyser des attaques destructrices sans 
affecter le systeme reel. 
25 Le dispositif peut aussi etre utilise en tant qu'outil d'aide a la conception 

de la securite de systemes en cours de conception ou de realisation, ce qui 
permet la mise au point et le test de leur politique de protection avant meme 
leur installation. 

II peut aussi etre utilise en tant qu'outil privilegie de certification de 
30 systeme, au sens de la certification securite selon la normalisation existante: 
TCSEC, ITSEC ("Information Technology Security Evaluation Criteria") et CC 
("Common Criteria"). Cette normalisation permet en effet actuellement de 
certifier des produits aux contours nettement delimites, mais est jusqu'a 
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maintenant inapplicable aux systemes. Ces derniers sont en effet trop vastes, 
complexes, heterogenes, aux contours mal definis et evolutifs, pour etre 
lvalues avec les techniques devaluation de produits. 

En resume, le dispositif est un outil destine a des specialists de la 
5 securite: administrateurs systeme, auditeurs techniques de la securite. A ces 
personnes, il apporte en plus la possibility d'adopter le point de vue de 
I'attaquant, point de vue absolument necessaire pour construire une protection 

efficace et adaptee. 

D'autres caracteristiques et avantages de I'invention apparaitront 
10 encore a la lecture de la description qui va suivre. Celle-ci est purement 
illustrative et doit etre lue en regard des dessins annexes sur lesquels : 

- la figure 1 est un diagramme illustrant les phases de moderation et 
de simulation selon le procede de I'invention ; 

- la figure 2 est un schema synoptique illustrant les elements d'un 

1 5 dispositif selon I'invention ; 

-la figure 3 est un schema illustrant la construction d'un modele 
composants / relations pour un systeme d'information ; 

-la figure 4 est un schema montrant un exemple de modele 
composants / relations, sur lequel apparaissent des relations d'hebergement et 
20 des relations d'echange entre des composants ; 

- la figure 5 est un schema illustrant des exemples de relations de 
service entre des composants d'un systeme d'information modelise selon 
I'invention ; 

- la figure 6 est un schema qui illustre un exemple detailte de la phase 
25 de simulation du procede selon I'invention 

- les figures 7a a T sont des schemas qui illustrent des exemples de 

chemins d'attaque ; 

- la figure 8 est un schema montrant la transmission d'une attaque a 
travers un chemin d'attaque dans un systeme d'information modelise ; 

30 - la figure 9 et la figure 1 0 sont des schemas presentant un mecanisme 

de piles amont et aval ; 

- la figure 11 est un schema illustrant un exemple de fonctionnement 

des piles amont et aval ; 
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-la figure 12 est un diagramme illustrant I'algorithme general de 
fonctionnement du moteur attaques / parades ; 

- la figure 13 est un diagramme qui illustre un mecanisme d'application 
des regies de protection ; 

5 - les figures 14a et 14b sont des diagrammes illustrant un mecanisme 

de routage fonctionnel et un mecanisme de contagion d'etats, respectivement ; 

- la figure 15 est un schema illustrant des techniques de detournement 
dans un systeme d'information modelise ; 

-la figure 16 est un schema illustrant I'affichage d'un systeme 
10 modelise, avec une fonctionnalite multi-vues ; 

-la figure 17 est schema illustrant I'affichage multi vues selon une 
approche hterarchique ; et, 

- la figure 18 est un schema synoptique d'un dispositif selon l'invention. 
Comme illustre par le graphe de la figure 1 , le procede comporte deux 

1 5 phases d'utilisation, elles meme decomposees en deux etapes. 

Pendant une phase de modelisation, I'utilisateur adopte le point de vue 
du defenseur. La phase de modelisation comprend une etape 1 de 
specification de I'architecture du systeme avec un ensemble de composants du 
systeme et des relations entre lesdits composants, qui comprennent des 

20 relations de propagation et des relations de service. L'etape 1 aboutit a 
I'architecture modelisee du systeme reel, appelee modele 
composants / relations dans la suite, ce module etant sauvegarde sous la 
forme d'un fichier dans une memoire 1 1 . tie modele peut etre represents de 
fagon graphique par un graphe comportant des boftes symbolisant les 

25 composants, reliees par des fleches symbolisant les relations. La phase de 
modelisation comprend aussi une etape 2 de specification de regies de 
comportement, a ne pas confondre avec les relations prScitees. Ces regies de 
comportement d&finissent le fonctionnement de chaque composant, aux plans 
du fonctionnement et de la securite, en particulier les protections qu'il assure. 

30 L'etape 2 aboutit a la construction d'un fichier de regies de comportement, qui 
est sauvegarde dans une memoire 12. 

A I'inverse, pendant une phase de simulation, Putilisateur adopte le 
point de vue de Pattaquantl La phase de simulation comprend une etape 3 de 
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specification des attaques, qui aboutit a la cr6ation d'un ou plusieurs scenarios 
d'attaques. Ces scenarios sont sauvegardes sous la forme de fichiers dans une 
memoire 1 3. La phase de simulation comprend aussi une etape 4 de simulation 
interactive d'attaques. Cette simulation est realisee par un moteur 

5 attaques / parades. Elle aboutit £ la creation d'un journal des attaques, qui est 
sauvegarde sous la forme d'un fichier dans une memoire 14. 

Les fichiers sauvegardes dans les memoires 11, 12, 13 et 14 peuvent 
etre importes de ou exportes vers differentes applications, en sorte que leur 
reutilisation est possible. 

10 Les phases de modelisation 10 et de simulation 20 peuvent etre iterees 

de faQon alternee, en modifiant a chaque fois tout ou partie des parametres 
(modele composants / relations, regies de comportement, attaques) pris en 
compte. Ceci permet une bonne maTtrise de la securite du systeme ? par 
I'utilisateur. ^ 

15 Dans la suite de la description, il est decrit un mode de mise en oeuyre 

des stapes 1 a 4 du procede, avec toutefois une presentation modifiee quarit a 
I'ordre des etapes. En effet, I'etape 3 (specification d'attaques) et I'etape 4 
(simulation interactive par moteur attaques / parades) sont exposees avant 
I'etape 2 (parametrage des regies de protection), pour aider a la 

20 comprehension du texte. En outre, la description de ces etapes est completee 
par une presentation de deux mecanismes complementaires : les metriques et 
('interface Homme / machine (IMM). > .'.-** 

Au prealable, les principaux elements d'uh dispositif selon Tinvention 
sont presents en reference au diagramme fonctionnel de la figure 2. Sur cette 

25 figure, on a represents en partie haute un groupe 20a des elements utilises 
pendant la phase de modelisation, et en partie basse un groupe. 20b de ceux 
utilises pendant la phase de simulation. De plus, une interface 
Homme / machine 15 est representee sur la droite. 

Le groupe 20a comprend un langage de regies 21 permettant 

30 d'elaborer les regies de protection 22, un ensemble de metriques de base 23, 
et le modele composants / relations 24. 

Le groupe 20b comprend un langage d'attaques 25 permettant 
d'elaborer les scenarios d'attaques 26, le moteur attaques / parades 16, un 
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mecanisme de piles amont et aval 27, un ensemble d'etats potentiels 28 et des 
metriques calculees 29. 

A la figure 2, les fleches en traits continus symbolisent les transferts 
d'informations entre les elements, et les traits discontinus symbolisent les liens 
5 fonctionnels entre les elements. Le role de chacun de ces elements apparaTtra 
dans ce qui suit. 

La premiere etape du procedS, etape 1, consiste a construire le modele 
composants / relations (ou architecture) du systeme reel via I'interface humaine 
15. Pour cela, le systeme est decompose en composants §lementaires (ou 
1 0 atomes), dotes d'attributs, et relies par des relations. 

Les Stapes de la construction du modele composants / relations sont 
illustres par le graphe de la figure 3. 

Une premiere etape 31, Putilisateur met en place sur un graphe a deux^ 
dimensions les composants qui forment le systeme. Dans un exemple, chaque : 
15 composant est represents par un rectangle contenant ses quatre etats^ 
potentiels et son nom. 

Les composants peuvent representor toutes sortes d'objets reels^- 
heterogenes de type physique (site, batiment, etage, local, bureaux coffre,- 
porte, fenetre, serrure, cle,...), support (papier, disque fixe, disquette, CDROM, 
20 bande magnetique,...), reseau (electrique, informatique, tSlephonique, hertzien, 
aerien,...), materiel (mecanique, reseau, informatique, poste, .serveur, ecran, 
clavier, imprimante,...), logiciel (OS, driver, application, service,...), donnees 
(repertoire, fichier, information, base de donnees, mot de passe,...), personnes 
(utilisateur, agresseur, directeur, administrateur, organisation, service, ...), etc. 
25 Cette liste indicative et non limitative. 

Chaque composant a plusieurs attributs, qui sont definis dans une 
etape 32. Les attributs comprennent des attributs statiques et des attributs 
dynamiques. Les attributs statiques comprennent par exemple un nom 
(compost d'une nature et d'un identifiant), et eventuellement un ou plusieurs 
30 adjectifs. Les attributs dynamiques comprennent par exemple des etats 
potentiels dits etats "ACID" (voir plus loin), un nom pretendu (dans le cas ou le 
composant est usurpateur), et un lien vers un composant usurpateur (dans le 
cas oCi le composant est usurp§). 
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Les adjectifs ont pour but de permettre de designer des composants 
sans les nommer, et ceci soit dans des regies (par exemple: tous les 
composants "externes" sont interdits d'acces), soit dans des attaques (par 
exemple: decouvrirtous les composants "IP"). La liste des adjectifs est ouverte, 
5 et definie par I'utilisateur lors de la modeiisation. Un exemple d'adjectifs classes 
par utilite est donne par la tableau I ci-dessous : 



F utilite 


adjectifs 


appartenance 


interne, externe, prive, public, 6tablissement, groupe, 
central, local, distant 


sensibilite, gravite 


normal, important, critique, vital, droits reserves (DR), 
confidentiel defense (CD), secret defense (SD), top- 
secret defense (TSD), tactique, strategique 


droit d'acces, role 
technique ou 
lorganisationnel, 
interne ou externe 


usager, redacteur, lecteur, editeur, technicien, operateur, 
exploitant, administrateur, stagiaire, employe, gardien, r ? A 
surveiilant, responsable, gestionnaire, directeur, client, J 
partenaire, consultant, fournisseur, client, concurrent 


confiance ou 
rfiefiance 


fiable, fidele, sincere, serieux, connu, inconnu, douteux^d 
suspect, pirate 


technique 


IP, reseau, informatique, OS, executable, information, 
fixe, mobile. " 


protection 


crypte, cache, secouru, repertory, administre, duplique ; | 



Tableau I 



10 La modeiisation etant une tache complexe pour I'utilisateur. C'est 

pdurq'ubi les m6canismes de modeiisation sont congus pour fonctionner meme 
sur un modele non completement termine, done eventuellement partiellement 
incoherent. Ceci permet a I'utilisateur de travailler selon un processus 
progressif et iteratif, alternant la modeiisation et les tests de fonctionnement par 

15 simulation. 

Les composants sont ubiquistes et intemporels. Ce principe a pour but 
de simplifier le travail de modeiisation, sans nuire au realisme, dans la mesure 
ou le theme est la securite. II se traduit concretement par !e fait qu'un 
composant peut etre, notamment : 
20 -multiple, e'est-a-dire representer plusieurs objets reels semblables 

situes en plusieurs endroits ; 
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- disperse, c'est-a-dire representer un objet de grande taille non situe 
dans une zone precise (par exemple un reseau); 

- partiel, c'est-a-dire representer une partie d'un objet reel complexe ; 

- replique, lorsque deux composants peuvent representer !e meme 
5 objet reel (par commodity de moderation) ; 

-duplique, lorsque, par exemple, un meme fichier reel presente 
plusieurs copies sur plusieurs supports ; 

- temporaire, c'est-a-dire representer par exemple une communication 
telephonique intermittente ; et 

10 - mobile : par exemple, un poste portable, ou une personne sont 

mobiles ("nomades") par nature. 

Dans une etape 33, ont definit des relations de propagation associees 
aux composants. Ces relations sont bidirectionnelles, et susceptibles de; 
vehiculer des attaques dans les deux sens. Elles peuvent §tre de deux types* 
15 distincts : de type hebergement (contenance, alimentation) et de type echange.^ 
Le schema de la figure 4 illustre un exemple de relations- 
d'hebergement (symbolisees par des f leches verticales) entre un logiciel client" 
41, un poste de travail 42 (un ordinateur personnel ou PC) dans lequel ledit- 
logiciel client est sauvegarde, et un bureau 43 dans lequel ledit poste de travail 
20 est situe. Le meme schema illustre aussi des relations d'echange entre le 
logiciel client 41 et un logiciel serveur 44 avec lequel le logiciel client echange- 
des donnees, entre le poste de travail 42 et un reseau informatique auquel le 
poste de travail est raccorde 45, et entre le bureau 43 et un couloir 46 
permettant I'acces audit bureau. 
25 Quand un composant est traverse par une attaque, il peut ou non 

laisser une trace du passage dans I'attaque. Par exemple, un paquet postal 
porte le cachet du bureau de poste emetteur, mais pas du bureau de poste 
recepteur. De meme, un paquet IP ("Internet Protocol") contient ou non 
Padresse IP d'un routeur traverse. 
30 Pour prendre en compte cette realite, chaque composant, pour 

chacune des relations qu'il regoit, a un indicateur de transparence ou opacite. 
S'il est transparent, il ne sera pas vu des composants avals sur le chemin de 
I'attaque, et ces composants ne pourront done pas en tenir compte dans leurs 
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regies de protection. Si au contraire ii est opaque, les composants avals le 
verront, mais il cachera les composants amonts de meme type (c'est a dire 
ayant les memes adjectifs). 

A cote des relations de propagation, on prevoit aussi des relations de 
5 service, qui sont definies dans une etape 34. Les relations de service sont 
unidirectionnelles, et ne vehiculent pas d'attaques. Elles ont pour but de 
permettre de designer un composant a partir d'un autre, sous la forme d'une 
indexation. 

Le schema de la figure 5 illustre un exemple de relation de service. Sur 
10 cette figure, on a represente un poste de travail 51, une personne 52, un mot 
de passe 53 et un bureau 54. Des relations de propagation entre ces 
composants sont symbolisees par des traits continus, et des relations de 
service sont symbolisees par des traits discontinus le composant. Dans cet 
exemple, le composant "mot de passe" 53 peut etre designe par la formule 
15 "passe(personne)". De meme, le composant "bureau B24" peut etre designe 
par "bureau(personne)". 

De retour a la figure 3, on notera que les etapes 31 a 34 peuvent etre 
iterees pour permettre a Tutilisateur d'affiner la construction du modele 
composants / relations. 
20 Quand le modele composants / relations est termini, une table de 

routage est construite dans une etape 35. Cette "table est calculSe 
automatiquement selon le principe du plus court chemin entre les composants, 
en utilisant les relations de propagation uniquement. Le resultat est par 
exemple une matrice composant de depart / composant d'arrivee. 
25 L*6volution dans le temps de chaque composant est . memorisee au 

moyen de quatre etats potentiels, appeles etats "ACID" (A = activite, 
C = confidentialite, I = integrity D = disponibil'rte). Ces etats correspondent aux 
trois domaines connus de la securite (C, I, D), auxquels a ete ajoute I'etat "A" 
pour "activite". Ce dernier etat represente la capacity d'un composant a agir, 
30 soit de fagon normale (licite), soit de fagon malveillante, et ceci sous I'influence 
de I'agresseur. 
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On pourra noter que ces 6tats ACID correspondent sensiblement aux 
droits etementatres des modeles de securite: "XRWD" (X = execute, R = read, 
W = write, D = delete), lis sont independants les uns des autres. 

Dans un exemple chaque §tat a quatre valeurs possibles : normal, 
5 affaibli, degrade, dangereux. Dans un exemple, ces valeurs sont codees sur le 
graphe composants / relations par un code de couleur (par exemple vert, 
jaune, rouge, bleu fence, respectivement), utilise pour le remplissage du 
rectangle symbolisant chaque composant. 

Le tableau II ci-dessous donne la signification des quatre valeurs 
1 0 possibles des quatre etats ACID potentiels. 



I Etats ACID : 


Activite 


Confidential ite 


Integrite 


Disponibilite 


sain 


ferme 


discret 


integre 


disponible 


affaibli 


ouvert 


decouvert 


usurpateur 


sature ' 


degrade 


actif 


divulgue 


altere 


bloquev »■ 


| dangereux 


interactif 


trahi 


corrompu 


detruit . 



Tableau II 



Le but de I'analyse est d'etudier la possibility de realiser une intrusion 
15 dans un systeme. Dans la mesure ou il est n6cessaire de faire des 
simplifications par rapport a la realite, il est preferable de simplifier dans le sens 
du pessimisme, ceci dans un but securitaire. En d'autres termes, le dispositif 
peut voir des intrusions la oCi il n f y en n'a pas, mais ne doit pas oublier des 
intrusions reellement possibles. L'utilisateur fera ensuite la part des choses, si 
20 necessaire. 

Ce principe, dit de la "politique du pire" est appliqu6 dans le moteur 
attaques / parades de la maniere suivante. 

Au depart de la modelisation, les quatre etats potentiels de chaque 
composant sont respectivement initialises a la valeur "sain". L'utilisateur peut 
25 les initialiser manuellement a une valeur differente s'il le souhaite. Les etats ne 
peuvent ensuite evoluer que vers la degradation, au fur et a mesure des 
attaques r^ussies. 

Les etats sont "potentiels", e'est-a-dire qu'ils signifient que les 
composants "peuvent" se trouver dans les etats indiqu6s, mais pas forcement. 
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Ceci implique que deux etats apparemment incompatibles (par exemple, un 
composant a la fois "actif et "detruit") peuvent coexister. Quand deux etats 
sont incompatibles ou incoherents, le dispositif choisit la situation la plus 
defavorable au defenseur. 

5 Quand un composant (modelise) represente plusieurs objets reels, ses 

6tats potentiels sont ceux de I'objet reel le plus degrade. 

Enfin, le test d'un etat de composant dans une regie ne correspond pas 
a une relation d'egalite, mais a une relation d'ordre. Par exemple, le test 
"composant = bloque" est positif si le composant est soit "bloque", soit "detruit". 

10 On va maintenant decrire un exemple de mise en oeuvre de I'etape 3 et 

de I'etape 4 du precede, a savoir la specification des scenarios d'attaque et leur 
simulation interactive. A cet effet, il est fait reference au diagramme de la figure 
6. 

Dans une etape 61, une attaque est definie. Dans un exemple, il est 
15 prevu une attaque pour chaque degradation d'un etat ACID. Les attaques 
correspondantes sont appelees attaques elementaires dans la suite. Elles sont 
liees directement aux etats ACID. Par exemple, pour faire passer un 
composant a Tetat "bloque", on utilise I'attaque "bloquer". 

II y a done douze attaques elementaires (correspondant aux douze 
20 valeurs d'etats potentiels non saines), qui sont resumees dans le tableau II ci- 
dessous, plus une attaque speciale dite attaque d'usurpation. Cette derniere 
attaque, appelee "ChangerNomPretendu", permet a un composant d'usurper le 
nom d'un autre. L'usurpation est en effet une technique fondamentale de 
I'intrusion. 



25 





attaques 
ACID 


Activite 


Confidentialite 


Integrite 


Disponibilite 




faible 


ouvrir 


decouvrir 


usurper 


saturer 


grave 


active r 


espionner 


alterer 


bloquer 




dangereuse 


p6netrer 


trahir 


corrompre 


detruire 





Tableau 111 



Lors de la definition d'une attaque elementaire, I'utilisateur (qui se 
place du point de vue de I'attaquant) saisit les parametres suivants : 
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- type d'attaque, parmi les 13 ci dessus ; 

- type de protocole (voir ci dessous) ; et, 

- elements du chemin (voir plus loin). 

Le "protocole" generalise le concept de protocole de 
5 telecommunication, et designe tout moyen de transmission d'une attaque entre 
deux composants. Une attaque se concretise toujours par la transmission dans 
le systeme d'un objet reel, physique ou logique, vehiculant des informations, 
des logiciels ou des mecanismes malveillants. 

La liste des protocoles est ouverte, I'utilisateur pouvant en definir 
10 autant qu'il souhaite lors de la moderation. Des exemples de protocoles sont : 

- protocoles physiques : lettre, colis, disquette, CDROM, personne,.., 

- protocoles logiques et informatiques : mail, web, fichier, Telnet, 
Netbios, TCP/IP, FTP, SSL,... 

- protocoles specialises : missile, onde hertzienne, laser, ... 
15 -etc. 

Le langage d'attaque utilise les memes mots que le langage de regies, 
et permet de definir des scenarios d'attaques complexes. Une ligne d'attaque 
elementaire est par exemple : 

"depart=agresseur + intermediaire=lnternet + protocole=mail + arrivee=usager 
20 + attaque=detruire + cib!e=poste(usager)" 

En frangais, cette ligne d'attaque signifie que i'agresseur envoie, via Internet, 

un courrier electronique a I'usager, contenant une bombe logique qui va 

detruire son poste. 

Le chemin d'attaque est Tun des concepts centraux du dispositif, dont 
25 I'objet est justement de trouver des chemins d'attaque dans un systeme 

modelise. Lors de la simulation, I'utilisateur specifie le chemin sous la forme 

suivante : 

- un composant de depart ; 

- un composant d'arrivee ; 

30 - un composant cible ; et, eventuellement 

- un composant intermediate. 

L'agresseur et la cible doivent necessairement se trouver sur le 
chemin, mais pas necessairement au debut ou a la fin. Le schema des figures 
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7a a 7e montrent diverses possibilities (non limitatives) de chemin d'attaque, qui 
peuvent correspondre chacune & un cas reel Par exemple, lorsque la cible est 
un poste de travail : 

- a la figure 7a, I'agresseur sature le poste de travail par du trafic 
5 artificiel transmis via le reseau ; 

- £ la figure 7b, I'agresseur envoie un virus par courrier electronique qui 
est execute par un usager "pigeon", ce qui altere le poste de travail ; 

- a la figure 7c, i'agresseur est un serveur pirate, et c'est un usager 
"pigeon qui consulte une page web sur serveur pirate et recjoit un applet Java 

10 pirate qui altere le poste ; 

- a la figure 7d, I'agresseur est aussi un serveur pirate et le poste de 
travail (rendu actif) ouvre une "reverse back door" vers le serveur pirate ; et, 

- a la figure 7e, I'agresseur est un reseau altere par lequel passe une :> 
session, devoilant ainsi des informations du poste de travail. % 

15 Bien entendu, les exemples ci-dessus. sont illustratifs et nullement . 

limitatifs. 

De retour a la figure 6, 1'attaque specifiee a l'etape 61 est lancee dans& 
une etape 62. Dans une etape 63, elle est executee par le moteur '. 
d'attaques / parades. Et dans une derniere etape 64, le resultat de i'attaque est 
20 constate. Les etapes 61 a 64 sont iterees, etant executees pour chaque 
attaque du scenario d'attaques. 

Le resultat d'une attaque, si elle reussit, est de faire passer Tun des 
etats ACID du composant cibie a une valeur degradee (non saine), voire a une 
valeur degradee plus grave si il etait deja une valeur degradee. Par exemple 
25 dans le cas de I'attaque "bloquer" : 

- si le composant est moins degrade que "bloque" (par exemple, 
"sature"), alors il devient "bloque" ; 

- s'il est deja "bloque", alors il reste "bloque" ; et, 

- s'il est plus degrade que "bloque" (par exemple "detruit"), alors il ne 
30 change pas d'etat. 

On va maintenant decrire plus en details le fonctionnement du moteur 
d'attaques / parades. Typiquement, la transmission d'une attaque sur le chemin 
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d'attaque se fait selon trois phases successives, illustrees par le schema de la 
figure 8, a savoir : 

- une phase de propagation durant laquelie Pattaque traverse les 
composants vecteurs, qui peuvent ou non assurer un filtrage de securite via 

5 leurs regies de protection ; 

-une phase d'absorption durant laquelie Pattaque peut ou non 
degrader la cible, selon ses defenses propres (regies de protection) ; et, 

- une phase de contagion durant laquelie la degradation de la cible 
peut se communiquer a d'autres composants sans qu'ils puissent se defendre 

10 (par exemple, ('explosion d'un bureau entratne la destruction des equipements 
presents dans ce bureau). 

Quand une attaque arrive dans un composant, ie moteur 
attaques / parades effectue pour lui un certain nombre de centrales (regies), 
bases sur les etats de certains composants, et en particulier sur les, 
15 composants situes en amont et en aval sur le chemin de Pattaque. Pour ces, 
derniers, repr£sentes sur le schema de la figure 9, les informations dont 
dispose le moteur attaques / parades sont consignees respectivement dans la 
pile amont et dans la pile aval qui ont ete presentees plus haut en regard du 
schema de la figure 2. Ces piles amont et aval sont la moderation des 
20 indications portees sur les objets n£els (par exemple adresses et cachets de la 
Poste sur un colis, adresses IP sur un paquet IP, etc.). 

La pile amont donne la liste (dans Pordre) de tous les composants deja 
traverses par Pattaque. Dans un exemple, il y a precisement deux piles amont : 
Tune qui contient la liste exhaustive de tous les composants, avec leurnom 
25 reel, et Pautre qui contient uniquement la liste des composants opaques, avec 
leur nom pretendu. La premiere liste est utiiisee pour executer les regies de 
possibility et de contagion du composant. L'autre est utiiisee pour executer 
pour les regies de protection (identification, autorisation et routage). 

La pile aval donne la liste des destinataires identifies de Pattaque. II y a 
30 un destinataire final, et eventuellement un ou plusieurs destinataires 
intermediates. Ces destinataires intermediaires sont specifies, soit par 
Putilisateur lors de la definition d'une attaque, soit par le routage fonctionnel. La 
pile aval est utiiisee par les regies des composants. 
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DansH'exemple-fflustfe^ 

sont transparents (car Padresse IP source des paquets IP venant de Pexterieur 
est inchangee). C'est pourquoi, etant empiles dans la premiere pile amont 110 
des noms reels, et ils ne sont pas empiles dans la seconde pile amont 120 des 
5 noms visibles (c'est-a-dire reel ou pretendu, le cas echeant). Par ailleurs, le 
pirate 113 usurpe le nom d'un usager 114. Son "nom visible" (empile dans la 
seconde pile amont 120) est done "usager" et non "pirate". La pile aval est 
designee par la reference 130. 

Pour chaque transit d'une attaque, le moteur effectue les trois 

10 operations suivantes : 

- premierement, il determine le prochain composant destinataire de 
Pattaque: c'est le premier composant de la pile aval, 

- deuxiernement, il determine, grace a la matrice de routage local, 
quelle est la relation a emprunter pour aller vers ce composant ; et, 

15 - troisiemement, le composant qui se trouve de Pautre cote de la 

relation devient le composant en cours. 

L'attaque s'arrete quand la pile aval est vide (et non quand le 

composant d'arrivee est atteint, car d'autres composants peuvent etre empiISs 

en aval apres Parrivee). 
20 Pour le composant en cours (atteint par Pattaque), le moteur effectue 

les operations suivantes, illustrees par le schema de la figure 1 1 : 

- il extrait le composant en cours de la pile aval, s'il y est (etape 1) ; 

- il teste les regies de propagation du composant, qui peuvent accepter 
ou refuser Pattaque ; 

25 - si Pattaque est refusee, le moteur Parrete, sinon il continue les actions 

suivantes, 

- dans le cadre des regies de routage fonctionnel, il peut empiler un 
composant intermediate en aval (etape 2) ; 

- il empile le composant en cours dans la pile amont (etape 3) ; et 
30 - si Pattaque est acceptee, il la route vers le composant suivant. 

L'algorithme general de fonctionnement du moteur d'attaques / parades 
est donnee par le diagramme de la figure 12. 
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Sur ce diagramme, le mot-cle "moi" d6signe le composant en cours. 
Pour transporter ou absorber une attaque, le composant en cours doit etre 
dans Petat "ouvert" (etat A des etats ACID). Pour absorber Pattaque, le 
composant cible doit se trouver dans la premiere pile amont, celle des noms 
5 reels. On notera que les regies d'identification et d'autorisation donnent 
toujours "oui" pour resultat si le composant est corrompu. 

A la figure 12, les trois phases de la transmission de Pattaque, a savoir 
la propagation, Pabsorption et la contagion de Pattaque, sont representees 
separ§ment 

10 On va maintenant decrire Petape 2 du procede, qui est le parametrage 

des regies de protection des composants. 

Lorsque Parchitecture d'un systeme est specifiee (& la fin de Petape 1), 
cette architecture etant representee par le graphe composants / relations, ij 
reste en effet a decrire le comportement des composants, aux plans du-, 

1 5 fonctionnement et de la securite. 

A cet effet, Petape 2 consiste a parametrer le fonctionnement 6% : 
chaque composant, et en particulier a decrire les protections qu'il assure. Ceci v 
est fait au moyen de la saisie de regies, structurees selon un langage et un^,, 
grammaire de regies. 

20 Le langage de regies se caracterise par, a capacite au realisme (pour 

decrire precisement le fonctionnement d'un composant reel), Pergonomie pour 
Pusager (simplicity souplesse, naturel, peu de signes speciaux) et la genericite 
(c'est-a-dire le fait de permettre une reutilisation facile des regies d'un modeie a 
Pautre). 

25 Au plan de Pedition, le langage est de preference sous forme de texte 

ASCII ou XML, est lisible, modifiable et imprimable avec un traitement de texte 
classique (tels que Notepad, MS-Office), accepte des commentaires en 
langage naturel sous la forme: /* commentaire */, accepte les majuscules / 
minuscules et accents (mais qui ne sont pas discriminants), et utilise les 

30 caracteres "blanc" et "ligne suivante" uniquement pour la presentation. 

De preference, les mots du langage apparaissent de la meme fagon et 
sous la meme forme dans la representation graphique du modeie 
composants / relations, dans la specification des regies (langage de regies), 
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dans la specification des attaques (langage d'attaques), et dans le journal des 
attaques. 

Le langage est principalement un langage de predicats (ou criteres de 
condition logique), utilisant des operateurs logiques (tels que ET, OU, NON), 
5 des mots-cles (tels que "attaque", "amont", "aval", "protocole", "moi"), et des 
noms de composants sous forme directe ou par adjectif, ou encore par relation 
de service. 

Par exemple, le predicat "amont(person)=admin + attaque=corrompre" 
signifie que Tattaque "corrompre" est autorisee a passer dans le composant s'il 
10 y a en amont une personne ayant role "admin" (administrateur). 

Un exemple de mots-cles g§neriques, qui est illustratif seulement, est 
donn§ par le tableau IV ci-dessous. Par ailleurs, a ces mots cles generiques, il 
y a lieu d'ajouter les seize valeurs des etats potentiels et les douze valeurs des 
attaques. 
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mot-cle 


designe 


signification 


utilisable par | 


generique 




regies 


attaques 


amont 


composant 


en amont (regies possibility et 
contagion) 


+ 




amont 


composant 


en amont (autres regies) sous nom 
pretendu 


+ 




aval 


composant 


en aval 


+ 




moi 


composant 


en cours de traitement 


+ 




entree 


composant 


dernier traverse en amont (= 
relation d'entree) 


+ 




depart 


composant 


premier en amont 


+ 


+ jj 


Icible 


composant 


cible de I'attaque 


+ 


+ | 


arrivee 


composant 


point d'arrivee de I'attaque 


+ 


+ I 


attaque 


attaque 


type d'une attaque 


+ 


+ 


protocole 


protocole 


type de protocole 


+ 


+ 


intermediate 


composant 


impose sur le chemin de I'attaque 




+ 


estlicite 


mode 


indique si Pattaque est licite ou non 




+ 


present 


etat 


presence d'un composant dans 
une pile 


+ 




absent 


etat 


absence d'un composant dans une 
pile 


+ 




authentique 


etat 


etat d'un composant non usurpe 


+ 




usurpe 


etat 


etat d'un composant usurpe par un 
autre 


+ 




lusurpateur 


composant 


composant qui en usurpe un autre 


+ 





Tableau IV 



Le langage dediescription des composants permet d'ecrire des regies, 
5 qui comportent chacune un nombre variable de predicats (condition logique 
booleenne) et eventuellement d'actions. Pour chaque composant, il existe huit 
types de regies. Les regies ont deux caracteristiques independantes : 

- elles peuvent etre binaires (condition logique booleenne, donnant une 

valour oui / non) ou f o n ction nelles (condit i on logique i mpliq u an t une act i on de 

1 0 routage ou de contagion) ; et, 

- elles peuvent etre "de propagation" (dans les composants vecteurs 
des attaques) ou "d'absorption" (dans les composants cibles des attaques). 
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Dans un exemple, cinq regies de propagation et trois regies 
d'absorption sont donnees respectivement par le tableau V et par le tableau VI 
ci-dessous. 



regie 


type 


role 


exemple 


possibility 


binaire 


definit quelles attaques 
peuvent passer 


un logiciel ne peut pas 
transporter un colis postal 


laeniiTicaxion 
amont 


uinaire 


assure I luentiTication et 
Pauthentification des 
composants amonts 


une attaque sera acceptee 
si le mot de passe a ete 
prealablement divulgue 


identification 
aval 


binaire 


assure Identification et 
Pauthentification des 
composants avals 




autorisation 


binaire 


definit quelles attaques 
sont autorisees a 
passer 


un dispositif pare-feu 
("firewall") peut interdire 
les attaques de decouverte 
par paquets "Pang" V 


routage 


fonctionnelle 


definit vers quel 
composant diriger les 
attaques 


un routeur envo[e les " 
messages mail vers le - 
serveur mall j 



5 Tableau V 



regie 


type 


, role 


exemple " 


possibility 


binaire 


definit quelles attaques 
peuvent passer 


un bureau peut absorber 
une bombe physique, mais 
pas une bombe logique 


identification 
amont 


binaire 


assure identification et 
Pauthentification 
eventuelle des 
composants amont 


une attaque sera acceptee 
si le mot de passe a ete 
prealablement divulgue 


contagion 


fonctionnelle 


definit quels etats 
doivent etre propag§s 
vers quels composants 


('explosion d'un bureau 
entraTne la destruction des 
equipements heberges 



Tableau VI 



Le regies sont appliquees de la fagon suivante. Chaque fois qu'une 
10 attaque se presente devant un composant (en cours), le moteur 
attaques / parades deroule le mecanisme illustr6 par le diagramme de la figure 
13. 
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Pour qu'une attaque soit propagee par un composant vecteur ou soit 
absorbSe par un composant cible, chaque categorie de regie binaire doit, soit 
etre vide, soit comporter une r6gle avec resultat positif. 

Si I'attaque est acceptee par un composant vecteur, celui ci applique 
5 les regies de routage fonctionnel selon le mecanisme illustr6 par le diagramme 
de ia figure 14a. De meme, si I'attaque est acceptee par le composant cible, 
celui ci applique les regies de contagion selon le mecanisme illustre par le 
diagramme de la figure 14b. 

On va maintenant decrire les mecanismes de routage local et 
10 fonctionnel. Le routage a pour fonction de diriger les attaques d'un composant 
a I'autre, dans !e but d'atteindre le point d'arrivee ou les points intermediates. II 
existe deux sortes de routages. 

Premierement, le routage fonctionnel, defini par I'utilisateur via les", 
regies de routage, et qui permet de definir un nouveau composant! 
1 5 intermediate avant d'atteindre le point d'arrivee. Ce composant est insere dans ^ 
la pile aval. Par exemple, un routeur decide de router un courrier electronique^ 
venant de Pexterieur vers le serveur de messagerie. } 
Deuxi§mement, le routage local, invisible de I'utilisateur, qui a pour; 
effet de diriger I'attaque vers le prochain composant de la pile aval, selon le ~ 
20 chemin le plus court. La table de routage local est utilisee a cet effet. On 
rappelie que cette table est construite automatiquement en fin de mod^lisation, 
selon le principe de recherche du plus court chemin. Dans un exemple, elle est 
structuree sous forme de matrice (composant de) depart / arrivee. 

Le routage fonctionnel permet d'assurer a la fois le fonctionnement 
25 nominal du systeme, et certaines fonctions de securite. Par exemple, un 
routeur qui envoi les paquets IP vers un dispositif par(feu ("firewall") assure 
une fonction de securite. Cette fonction de s§curite peut etre degradee dans le 
cas du detournement, ainsi qu'il va maintenant etre decrit. - 

La technique de detournement, fondamentale dans les scenarios 
30 d'attaque, peut etre prise en compte par le dispositif. Cette technique consiste 
a modifier la fagon dont est fait le routage fonctionnel. II trois sortes de 
detournements, illustrees par le diagramme de la figure 15. 
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A la figure 15 on a represente un exemple de chemin de propagation 
allant d'un client 151 & un serveur 155 a travers (dans cet ordre) un premier 
routeur 152, un filtre 153 et un second routeur 154. 

Un premier detournement est un detournement par contournement, 
5 symbolise par la fleche 156. Dans I'exemple represente, le routeur 152 est 
alter§ en sorte que son composant aval, le filtre 153, est supprime. 

Un deuxieme detournement est un detournement par interception, 
symbolise par les fleche 158a et 158b. Dans I'exemple represente, le routeur 
152 est altere en sorte qu'un composant aval 157 est ajoute sur le chemin de 
10 propagation. Ce composant aval est un pirate (usurpant). Dans ce cas, le 
serveur 155 est dit usurpe. 

Un troisieme detournement est un detournement par usurpation, 
symbolise par la fleche 150. Dans I'exemple represente, le routeur 154 est 
altere en sorte que son composant aval, le serveur 155, est remplace par un. 
15 autre composant aval 159. Cet autre composant aval est un pirate (usurpant)^ 
le serveur 1 55 est dit usurpe. & 
Un detournement peut etre realise par tout composant ayant une 
fonction de routage, situe dans le chemin de l'attaque. II est declenche par la 
reunion de trois conditions : 
20 - le composant de routage a un etat "altere" (indiquant que ses tables 

de routage sont alterees) ; 

- le composant d'arrivee est "usurpe" (du moins pour Pusurpation et 
interception) ; et, 

- le composant de routage a une (ou plusieurs) regie particuliere qui 
25 pr£voit le detournement. 

On va maintenant presenter un premier mecanisme supplementaire de 
invention, constitue par les metriques de faisabilite et de non detection. 

Les metriques ont pour but de completer le langage de regies, qui est 
principalement axe sur la protection par prevention. Elles permettent de 
30 relativiser le succes ou I'echec des attaques, en calculant un coefficient de 
faisabilite et de non detection, apportant ainsi la protection par detection. 
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Dans un exemple, il existe cinq metriques dont trois metriques de base, 
qui sont parametrees lors de la modelisation, et deux metriques de probabilite 
de sinistre, qui sont calculees lors de la simulation. 

Pour eviter de tomber dans le travers de la complexity les metriques 
5 de base sont evaluees sur un nombre restraint de niveaux, par exemple quatre 
niveaux. Cette echelle de niveaux doit etre comprise comme une echelle 
logarithmique, c'est a dire que chaque niveau implique un coefficient 
multiplicateur par rapport au niveau inferieur. Les quatre niveaux 
correspondent par exemple aux valeurs 0.1%, 1%, 10%, 100%. 
10 Deux metriques de base relevent du point de vue du defenseur. II s'agit 

d'une metrique d'efficacite des parades (resistance), et d'une metrique 
d'efficacite de detection des attaques. Ces 2 metriques sont parametrees par le 
I'utilisateur pendant la phase de modelisation, independamment pour chaque 
regie de protection dans chaque composant, selon une echelle de valeurs telle 
1 5 que faible, moyen, fort, absolu. 

En outre, une metrique de base releve du point de vue de I'attaquant. II 
s'agit d'une metrique de moyens de I'attaquant. Cette metrique comprend par 
exemple les aspects suivants: competence, outils, argent, temps. Elle est 
parametree par I'utilisateur pendant la phase de simulation, de fagon globale 
20 pour I'attaquant, tous moyens, toutes attaques et toutes cibles confondus. 
L'echelle de valeurs est par exemple : public, initie, specialiste, expert. 

Les metriques de probabilite de sinistre sont calculees par le moteur 
attaques / parades lors du passage dans chaque composant, puis consolidees 
par le moteur sur tout le chemin, puis sur tout le scenario. II s'agit d'une 
25 metrique de probabilite de passage d'une attaque sur un composant, d'une 
part, et d'une metrique de probabilite de non detection d'une attaque sur un 
composant, d'autre part. De preference, elles sont exprimees sur l'echelle a 
quatre niveaux des metriques de base, a laquelle on ajoute le niveau 0%, et 
elles sont calculees selon les formule suivantes : 
30 - probabilite de passage = (moyens de I'attaquant) / (efficacite de la 

protection) ; 

- probabilite de non detection = (moyens de I'attaquant) / (efficacite de 
la detection). 
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Le tableau VII ci-dessous donne le calcul des metriques calculees. 



efficacite 
du 

defenseur 


0.1% 


faible 


0.1% 


1 .0% 


10.0% 


100.0% I 


1 .0% 


moyen 


0.0% 


0.1% 


1 .0% 


10.0% 


10.0% 


fort 


0.0% 


0.0% 


0.1% 


1.0% 


100.0% 


absolu 


0.0% 


0.0% 


0.0% 


0.1% 


moyen 


s de I'attaquant <=> 


public 
0.1% 


initie 
1.0% 


specialiste 
10.0% 


expert 
100.0% 



Tableau VII 



5 On va maintenant decrire un autre mecanisme supplemental de 

I'invention, qui fait partie de Pinterface Homme / machine. 

Avantageusement, I'interface Homme / machine presente une 
fonctionnalite dite "multi vues". Ceci n'est pas en soi une originalite, car la 
plupart des logiciels utilisent ce genre de fonctionnalite. Ce qui est original, par 
10 contre, c'est I'utilisation des vues pour aider I'utilisateur a maitriser des 
systemes complexes, grace a une association entre les vues (logicielles) et les 
sous-systemes (conceptuels). 

Le systeme des "vues" est un element important de I'interface 
Homme / machine, qui permet la moderation de systemes complexes. Son 
15 principe est de decomposer le systeme en plusieurs vues, dont une seule est 
affichee a I'ecran dans la fenetre principale, I'utilisateur pouvant passer 
alternativement d'une vue a I'autre. Tout composant peut §tre place dans une 
vue, dans une autre, ou dans plusieurs vues, au choix de I'utilisateur. 

Le schema de la figure 16 montre un exemple de representation 
20 graphique d'un systeme (modelise) selon trois vues superposees. Le 
serpention symbolise un chemin d'attaque passant par les trois vues. 

II n'y a pas de contraintes pour la definition des vues, et pour la 
repartition des composants dans les differentes vues d'un systeme. On peut 
par exemple mettre en place des vues associees aux differents metiers du 
25 systeme (geographique, informatique, organisationnel). 

Avantageusement, moyennant certains principes simples, pris 
isolement ou en combinaison, les vues deviennent cependant un element de 
structuration fonctionnelle des systemes. 
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Selon un premier tel principe, chaque vue represente de preference un 
sous-systeme relativement autonome et independant du reste du systeme. 

Selon un deuxieme tel principe, on fait en sorte, de preference, qu'il 
n'existe pas de relations de propagation ni de services entre deux vues. Seuls 
5 les composants communs a deux vues assurent la fonction d'interconnexion 
entre les vues. 

Selon un troisieme tel principe, enfin, les regies des composants situes 
dans une vue ne doivent pas faire appel nommement a des composants situes 
dans une autre vue. 

10 Plus generalement, il y a deux facons de concevoir les vues. Soit les 

vues sont considerees comme des sous-systemes de meme niveau 
interconnects entre eux (par exemple, des sites interconnects via Internet, le 
composant commun etant Internet). Ou bien Tune des vues est consideree 
comme une description globale du systeme, tandis que les autres represented 

15 des details de tel ou tel composant complexe. Cette approche est appelee 
approche hierarchique et va etre detaillee maintenant. 

L'approche hierarchique est tres puissante, car elle permet d'assembler 
des composants detailles et mis au point prealablement pour former par 
assemblage des systemes tres complexes et realistes, tout en restant simple a 

20 visualiser. 

Dans cette approche, illustree sous la forme d'un exemple donne a la 
figure 17, une vue sup§rieure pr§sente le systeme global, qui contient un ou 
plusieurs composants representant chacun un sous-systeme. Chaque vue 
inferieure donne le detail d'un sous systeme. A la figure, le serpentin symbolise 
25 un chemin d'attaque passant par les deux vues. 

Un composant A commun a la vue superieure et a une vue inferieure, 
appele "composant relais", represente le sous systeme vu du systeme global, 
et reciproquement. Le composant relais est I'unique interface entre les deux 
vues. 

30 Le composant relais assure I'etancheite entre les vues, tout en 

assurant la communication entre elles, selon un triple role. 

Le composant relais assure tout d'abord un role de relais de routage. 
En effet, il assure le routage des attaques dans les deux sens entre les deux 
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vues. II utilise pour cela tous les criteres de routage disponibles dans le 
langage de regies. 

Le composant relais assure ensuite un role de relais de service. En 
effet, il peut avoir des relations de service, partant ou aboutissant, dans les 
5 deux vues. Ceci permet de designer un composant d'une vue a Pautre via 
Pindexation. 

Le composant relais assure enfin un role de relais de contagion d'etat. 
A cet effet, il assure pour la vue superieure une vision synthetique de la vue 
inferieure, via une contagion des principaux etats repr6sentatifs de cette vue. 

10 A la figure 18, sur laquelle les memes elements qu'aux figures 1 et 2 

portent les memes references, on a represents le schema synoptique d'un 
exemple de realisation d'un dispositif selon Pinvention. Ce dispositif convient 
pour la mise en ceuvre du procede selon Tinvention. . r , 
Dans cet exemple, le dispositif est impl6mente dans un ordinateur- a, 

15 usage general comprenant un microprocesseur 10. L'interfaca, 
Homme / machine 15 et le moteur attaques/ parades 16 sont mis en oeuvrp.: 
sous la forme de modules logiciels, sauvegardes dans une memoire 17 et plus, 
particulierement dans une memoire a lecture seule (ROM), lis sont executes, 
par le microprocesseur 10 lorsqu'ils sont charges dans la memoire vive de 

20 Pordinateur. 

Pour assurer Pentree de donnees par Putilisateur, le dispositif 
comprend un clavier 19b, et en general egalement une souris (non 
representee) ou similaire. Pour Paffichage des donnees, notamment pour 
Paffichage de la representation graphique du systeme modelises sous la forme 
25 d'une on plusieurs vues, le dispositif comprend aussi un ecran. Ces elements 
sont ceux qui equipent Pordinateur. 

Enfin, le dispositif comprend une memoire vive 18, en particulier une 
memoire a acces aleatoire (RAM), dans laquelle les fichiers 11, 12, 13 et 14 
peuvent etre sauvegardes. 

30 
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REVINDICATIONS 



1 . Procede d'analyse de la security d'un systeme d'information 
comprenant : 

-une phase de modelisation (1,2), comprenant la moderation du 
systeme d'information, 
5 -une phase de simulation, comprenant la specification (3) et la 

simulation (4) d'attaques potentielles centre le systeme d'information. 

2. Procede selon la revendication 1, suivant lequel la phase de 
modelisation comprend la specification (1) de I'architecture du systeme avec un 
ensemble de composants du systeme et des relations entre lesdits 

10 composants. 

3. Procede selon la revendication 2, suivant lequel, un nom §tant 
associe a chaque composant, un ou plusieurs adjectifs peuvent aussi etre 
associes audit composant, lesquels adjectifs permettent de designer ledit 
composant sans le nommer. 

15 4. Proced§ selon la revendication 2 ou la revendication 3, suivant 

lequel des etats determines sont associes a chaque composant du systeme 
d'information, chaque etat pouvant prendre une valeur saine et une ou 
plusieurs valeurs non saines. 

5. Procede selon la revendication 4, suivant lequel certains au moins 
20 desdits etats se rapportent respectivement a Tactivite, a la confidentialite, a 

I'integrite et/ou a la disponibilite du composant auquel ils sont associes. 

6. Proc6de selon Tune quelconque des revendications 2 a 5, suivant 
lequel un nom pretendu peut etre associe a un composant determine 
quelconque, notamment dans le cas oli ledit composant determine est 

25 usurpateur. 

7. Procede selon Tune quelconque des revendications z a 6, suivant 
lequel un lien vers un autre composant peut etre associe a un composant 
determine quelconque, notamment dans le cas ou ledit composant determine 
est usurp§ et ou ledit autre composant est usurpateur. 
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8. Procede selon Tune quelconque des revendications 2 & 7, suivant 
lequel les relations entre deux composants determines quelconques, 
comprennent des relations de propagation bidirectionnelles susceptibles de 
vehiculer des attaques dans les deux sens. 

5 9. Procede selon Tune quelconque des revendications 2 a 8, suivant 

lequel les relations entre deux composants determines quelconques, 
comprennent des relations de service permettant de designer un composant & 
partir d'un autre composant. 

10. Procede selon la revendication 2 F suivant lequel la phase de 
10 modelisation comprend en outre la specification (2) d'un ensemble de regies de 

comportement associees aux composants du systeme. 

11. Procede selon la revendication 10, suivant lequel chaque regie de 
comportement comprend un ou plusieurs predicats, et/ou une ou plusieurs,. 
actions. 

15 12. Procede selon la revendication 10 ou la revendication 11, suivant* 

lequel les regies de comportement comprennent des regies de propagations 
d'attaques, ces regies etant par exemple mises en ceuvre dans des, 
composants qui sont des vecteurs d'attaques, et des regies d'absorptiqn 
d'attaques, ces regies etant par exemple mise en ceuvre dans des composants 

20 qui sont la cible d'attaques. 

13. Procede selon Tune quelconque des revendications 10 k 12, 
suivant lequel les regies de comportement comprennent des regies binaires, 
par exemple des conditions logiques booieennes donnant une valeur de type 
oui / non, et/ou des regies fonctionnelles, par exemple des conditions logiques 

25 impliquant une action de routage (pour une regie de propagation) ou de 
contagion (pour une regie d'absorption). 

14. Procede selon Tune quelconque des revendications 2 a 13 
comprenant, a la fin de la phase de modelisation (figure 3), la construction (35) 
d'une table de routage local, permettant de diriger une attaque d'un composant 

30 de depart vers un composant d'arrivee. 
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15..p.rocede-selon_la_r.evendication JA,_J suivant lequeMa._table_de 

routage local est generee de facon automatique suivant le principe du plus 
court chemin entre le composant de depart et le composant d'arrivee. 

16. Precede selon Tune quelconque des revendications 3 a 15, suivant 
5 lequel I'etape de simulation des attaques comprend la mise a jour de I'etat d'un 

composant du systeme altere par une attaque reussie. 

17. Precede selon ia revendication 116, suivant lequel la phase de 
simulation comprend en outre la constitution d'un fichter ou journal des 
attaques, contenant I'historique des changements de I'etat des composants 

10 consecutifs a des attaques reussies, notamment pour permettre un traitement 
ulterieur par un utilisateur. 

18. Precede selon Tune quelconque des revendications precedentes, 
suivant lequel les attaques comprennent des attaques elementaires 
correspondant a des valeurs d'etats non saines. 

15 19. Procede selon Tune quelconque des revendications precedentes, 

suivant lequel les attaques comprennent en outre une attaque speciale 
d'usurpation. 

20. Procede selon I'une quelconque des revendications precedentes, 
suivant lequel une attaque est definie, notamment, par un type d'attaque, un 

20 type de protocole, et des elements de chemin d'attaque. 

21. Procede selon la revendication 20, suivant lequel les elements de 
chemin d'attaque comprennent un composant de depart, un composant 
d'arrivee, un composant cible, et le cas echeant un ou plusieurs composants 
intermediates. 

25 22. Procede selon la revendication 20 ou la revendication 21 , suivant 

lequel la liste des composants deja traverses par une attaque est sauvegardee 
dans au moins une ou plusieurs piles amont. 

23. Procede selon la revendication 22, suivant lequel les pile amont 
comprennent une pile (110) contenant la liste exhaustive de tous les 

30 composants traverses, designes par leur nom reel. 
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24. Procede selon la revendication 22 ou la revendication 23, suivant 
lequel les piles amont comprennent une pile (120) contenant la liste des seuls 
composants travers6s qui sont opaques, designes par leur nom reel ou, le cas 
ech6ant, par leur nom pretendu. 

5 25. Procede selon Tune quelconque des revendications 20 a 24, 

suivant lequel la liste des composants destinataires d'une attaque est 
sauvegardee dans au moins une pile aval (130). 

26. Procede selon Tune quelconque des revendications 10 & 25, 
suivant leque! les attaques sont definies dans un langage utilisant les memes 

10 mots qu'un langage dans lequel les regies de comportement sont definies. 

27. Procede selon Tune quelconque des revendications precedentes, 
suivant lequel la phase de modelisation et/ou la phase de simulation sont 
mises en oeuvre par un utilisateur au moyen d'une interface Homme/mactyne 
comportant une fonctionnalite multi vues, suivant laquelle une representation 

15 graphique du systeme est presentee a Tutilisateur en plusieurs vues. 

28. Procede selon la revendication 27, suivant lequel chaque-vue 
represente un sous-systeme du systeme, qui est relativement autonome et 
independant du reste du systeme, 

29. Procede selon la revendication 27 ou la revendication 28, suivant 
20 lequel la fonction ^interconnexion entre les composants compris dans deux 

vues distinctes est assuree seulement via le composant commun ou les 
composants communs aux deux vues. 

30. Procede selon Tune quelconque des revendications 27 a 29, 
suivant lequel les regies de comportement des composants appartenant a une 

25 vue ne font pas appel nommement a des composants appartenant a une autre 
vue. 

31 Procede selon Tune quelconque des revendications 27 a 30, suivant 
lequel les vues sont associees a des sous-systemes respectifs, par exemple de 
meme niveau, qui sont interconnects entre eux via au moins un composant 
30 commun. 
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suivant lequel une vue superieure est assoctee au systeme dans son 
ensemble, tandis qu'une ou plusieurs vues inferieures sont respectivement 
associees a un sous-systeme determine du systeme. 

5 33. Procede selon la revendication 32, suivant lequel un composant 

determine, commun 3 la vue superieure et a une vue inferieure determinee, 
represente le sous systeme correspondant vu du systeme dans son ensemble, 
et reciproquement. 

34. Procede selon la revendication 33, suivant lequel ledit composant 
10 commun est Punique interface entre les la vue superieure et ladite vue 

inferieure determinee. 

35. Proced§ selon Tune quelconque des revendications prec6dentes, 
suivant lequel la phase de modeiisation comprend en outre la specification 
d'une ou plusieurs metriques de base respectivement associees aux 

15 composants. 

36. Procede selon la revendication 35, suivant lequel !es metriques de 
base comprennent, une metrique d'efficacite des parades, une metrique 
d'efficacite de detection des attaques, et/ou une metrique des moyens d'un 
attaquant. 

20 37. Procede selon Tune quelconque des revendications precedentes, 

suivant lequel la phase de simulation comprend en le calcul d'une ou plusieurs 
metriques de probabilite de sinistra. 

38. Procede selon la revendication 37, suivant lequel les metriques de 
probabilite de sinistre comprennent une metrique de probabilite de passage 

25 d'une attaque sur un composant. 

39. Procede selon les revendications 36 et 38, suivant lequel la 
metrique de probabilite de passage d'une attaque sur un composant est 
calculee suivant la formule " probabilite de passage = (moyens de 
I'attaquant) / (efficacite de la protection)". 

30 40. Procede selon la revendication 37, suivant lequel les metriques de 

probabilite de sinistre comprennent une metrique de probabilite de non 
detection d'une attaque sur un composant. 
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41. Proceed selon les revendications 36 et 40, suivant lequel la 
metrique de probability de non detection d'une attaque sur un composant est 
calculee suivant la formule "probability de non detection = (moyens de 
Tattaquant) / (efficacite de la detection)". 
5 42. Dispositif pour la mise en oeuvre d'un procede selon Tune 

quelconque des revendications pr§cedentes, comprenant une interface 
Homme / machine (15) pour la mise en oeuvre de la phase de modelisation 
et/ou un moteur attaques / parades (16) pour la mise en oeuvre de ia phase de 
simulation 

10 43. Dispositif selon la revendication 42, dans lequel Pinterface 

Homme / machine pr£sente une fonctionnalite d'affichage en multi vues du 
systeme modelise. 

44. Dispositif selon la revendication 42 ou la revendication 43, dans 
lequel Tinterface Homme / machine permet d'afficher le systeme modeliS6 

1 5 selon un modele composants / relations. T 
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